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Scope 

Identification 

This  document,  IBM  Contract  Data  Requirements  List  (CDRL)  Sequence  Number  1490A,  is  the 
delivery  for  STARS  Delivery  Order  Task  R20  (Process/Environment  Integration). 


Purpose 

This  document  is  an  update  to  the  document,  IBM  Contract  Data  Requirements  List  (CDRL) 
1490,  Application  Blueprint  Definition  for  C3.  It  describes  the  application  blueprint  concept  and 
a  first  pass  of  the  domain  analysis  phase  of  an  application  blueprint  for  the  selected  C3  application, 
Air  Traffic  Control  Systems.  The  updates  to  CDRL  1490  include  additions  to  the  domain  analysis 
and  generic  architecture  discussions,  and  incorporation  of  the  peer  review  comments. 
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Abstract 

Application  Blueprints  serve  as  a  framework  for  designing  new  systems  in  an  application  domain, 
leading  to  reuse  of  design  information  and  greater  reuse  of  code.  This  document  discusses  the  de¬ 
finition  for  an  application  blueprint.  The  process  used  to  create  a  blueprint  is  outlined,  and  the 
benefits  and  drawbacks  of  an  application  blueprint  are  discussed.  The  Appendix  of  this  document 
presents  the  first  pass  of  the  domain  analysis  and  generic  specification  of  an  Application  Blueprint 
for  an  Air  Traffic  Control  System.  This  paper  should  be  used  as  the  groundwork  for  future  STARS 
work  in  the  reuse  of  analysis  and  design  information. 
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Introduction 


Most  of  the  components  reused  today  are  small  and  general  enough  to  be  adapted  for  use  in  many 
different  systems.  Although  some  productivity  is  gained  by  the  reuse  of  small  components,  reuse 
of  non-domain  specific  components  frequently  requires  a  large  amount  of  new  code  to  glue  the 
components  together  and  to  tailor  the  components  to  the  domain.  Reuse  of  small  pieces  of  code 
is  not  going  to  substantially  improve  the  productivity  of  systems  development.  A  greater  im¬ 
provement  in  the  productivity  and  quality  in  systems  development  can  be  achieved  by  reusing  de¬ 
sign  information. 

Studies  of  the  techniques  and  work  products  of  expert  designers  show  that  they  typically  do  not 
start  their  designs  from  scratch.  Instead  they  base  their  new  designs  on  previous  knowledge,  using 
the  same  patterns  repeatedly  in  their  designs.  “They  are  bringing  a  large  amount  of  pre-structured 
information  (i.e.  partially-specified  architectures)  to  bear  on  the  problem”  (Bigg87a). 

Application  blueprints  are  a  means  for  promoting  reuse  of  analysis  and  design  information  within 
a  domain,  resulting  in  a  significant  improvement  in  the  productivity  and  quality  of  system  devel¬ 
opment.  Reusable  architectures  will  reduce  the  design  time  for  the  total  system,  allowing  developers 
to  concentrate  on  designing  the  unique  features  of  each  system.  Also,  because  the  same  general 
framework  has  been  reused,  larger,  integrated  collections  of  components  can  be  reused  in  these 
systems,  reducing  the  total  development  time  for  the  system. 

Application  blueprints  serve  as  a  framework  for  designing  new  systems  in  an  application  domain. 
A  standard  set  of  interfaces  is  provided  by  the  application  blueprint  for  the  domain.  These  inter¬ 
faces  support  greater  reuse  of  analysis  information,  design,  and  code. 
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What  is  an  Application  Blueprint? 

Before  the  concept  of  an  application  blueprint  can  be  introduced,  one  needs  to  understand  the 
concept  of  a  domain  and  the  process  of  performing  a  domain  analysis. 


Domain 

A  domain  is  an  “encapsulation  of  a  problem  area”  (Neig84).  It  is  a  set  of  current  and  future 
systems/subsystems  marked  by  a  set  of  common  capabilities  and  data.  (SEI) 

(Quan88)  has  identified  two  types  of  domains  -  a  problem  domain  and  an  architectural  domain. 
The  problem  domain  contains  all  applications  that  are  part  of  the  domain  because  they  share 
common  functions.  An  architectural  domain  contains  all  domain  applications  that  are  in  the 
problem  domain  and  also  can  share  the  same  high  level  generic  architecture  and  set  of  reusable 
components.  The  problem  domain  may  contain  several  architectural  domains. 

A  problem  domain  may  be  composed  of  multiple  domains  that  are  less  application  specific.  “While 
some  domains  sound  very  problem  specific  such  as  an  Air  Defense  System  domain...these  domains 
are  primarily  built  out  of  general  and  much  more  reusable  domains  (ex.  database  domains)  which 
are  tailored  in  the  refinement  process  to  the  specific  problem.”  (Neig84) 


Domain  Analysis 

Domain  analysis  is  a  process  by  which  “common  characteristics  from  similar  systems  are  general¬ 
ized,  objects  and  operations  common  to  all  systems  within  the  same  domain  are  identified,  and  a 
model  is  defined  to  describe  their  relationships.”  (Prie87)  “Domain  analysis  can  be  seen  as  a  process 
where  information  used  in  developing  software  systems  is  identified,  captured,  structured,  and  or¬ 
ganized  for  further  reuse.”  (Prie90)  “Components  that  result  from  domain  analysis  are  better  suited 
for  reusability  because  they  capture  the  essential  functionality  required  in  that  domain.”  (Prie87) 
The  domain  analysis  process  involves  extensive  consultations  with  experts  in  the  domain  and 
analysis  of  existing  domain  applications. 

There  are  many  research  efforts  going  on  to  define  a  methodology  for  performing  the  domain 
analysis  (e.g.  the  work  of  the  Software  Reuse  Group  at  the  SEI,  Pittsburgh,  PA).  These  efforts 
are  based  on  applying  known  techniques  from  the  fields  of  artificial  intelligence  and  systems  analysis 
to  the  area  of  domain  analysis.  Knowledge  acquisition  and  knowledge  representation  techniques 
of  artificial  intelligence  can  be  used  for  obtaining  the  domain  knowledge.  System  analysis  tech¬ 
niques,  typically  used  for  analyzing  specific  system  requirements,  can  be  broadened  for  use  in  ana¬ 
lyzing  requirements  for  multiple  systems  Ln  a  domain  (Pric90). 


Application  Blueprints 

Application  blueprints  are  a  means  of  capturing  analysis,  design,  and  implementation  information 
for  a  specific  domain  in  a  fomi  which  facilitates  reuse  in  that  domain. 

A  blueprint  for  a  house  is  used  to  present  the  plan  for  building  a  house.  A  builder  can  create  many 
different  houses  from  the  same  basic  model  presented  in  the  blueprint  by  customizing  the  house. 
The  "interfaces"  for  the  builder's  components  are  specified  in  the  blueprint.  Specific  options  can 
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be  selected  such  as  adding  extra  rooms  or  selecting  different  styles  of  windows  and  doors  that  fit  the 
blueprint  specifications. 

Similarly,  an  application  blueprint  can  be  used  to  present  the  base  design  for  specific  applications 
in  a  domain.  The  generic  model  presented  in  the  blueprint  can  be  customized  to  create  a  specific 
application  .by  adding  new  functions  and  selecting  different  components  that  meet  the  interface  re¬ 
quirements  of  the  application  blueprint  and  fit  the  needs  of  the  specific  application. 

The  application  blueprint  provides  a  way  of  standardizing  the  software  interfaces  for  an  application 
domain,  similar  to  the  way  hardware  component  interfaces  have  been  standardized.  This  promotes 
greater  reuse  within  the  domain  by  increasing  the  probability  of  finding  acceptable  parts  that  can 
be  reused  as  black  boxes.  By  formalizing  the  standardization,  the  likelihood  of  finding  a  part  will 
be  increased  and  an  inter-organizational  sharing  of  parts  will  be  encouraged. 

The  application  blueprint  consists  of  the  following  parts: 

•  domain  analysis  information  -  notes  from  the  domain  analysis  process 

•  generic  functional  specification  -  requirements  for  the  high-level  design 

•  generic  high  level  design  -  the  generic  architecture,  providing  the  base  for  the  component 
structure,  i.e.  the  framework  for  integrating  the  set  of  domain  specific  reusable  components 

•  set  of  highly  integrated,  domain  specific  reusable  components 

•  generic  architecture  prototype  -  an  implementation  of  the  top  level  structure  of  the  generic 
system  that  will  be  used  as  the  initial  prototype  for  specific  applications  in  the  domain 

•  design  . and  implementation  information  -  Notes  on  design  rationale  and  tradeoffs 
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Figure  1.  Application  Blueprint 

Figure  1  emphasizes  the  strong  mapping  between  the  parts  of  an  application  blueprint.  Two-way 
traceability  between  any  two  of  the  pieces  of  the  blueprint  is  important  so  that  the  entire  blueprint 
can  be  developed  as  a  single  major  work  product  using  prototyping.  The  parts  within  an  applica¬ 
tion  blueprint  are  all  developed  concurrently  by  a  multi-disciplinary  team.  Each  team  member 
views  the  system  from  his  own  discipline.  These  views  must  be  consistently  represented  in  each 
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Figure  3.  Adaptive  Reuse 


(adapted  from  Boll89) 


What  is  an  Application  Blueprint? 


Application  blueprintspromote  a  hybrid  of  compositional  and  adaptive  reuse.  Each  structure  and 
new  piece  of  code  of  the  adaptive  reuse  system  can  be  created  using  compositional  reuse  techniques. 
For  example,  Structure  C  in  the  adaptive  reuse  example  in  Figure  3  could  be  composed  of  the 
connected  parts  in  the  compositional  reuse  example  Figure  2. 
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Advantages  and  Drawbacks  of  Application  Blueprints 

Advantages 

The  greatest  benefit  of  Application  Blueprints  is  that  it  leads  to  a  high  level  of  reuse.  By  orienting 
the  components  to  an  application  domain,  the  components  can  be  larger,  more  complex,  and  highly 
integrated,  leading  to  greater  reuse  within  the  domain.  (Quan88)  The  payoff  involved  in  reusing  a 
component  increases  more  than  linearly  as  a  component  grows  in  size  (Bigg87a).  Studies  have 
shown  that  “technologies  that  are  very  general,  in  that  they  can  be  applied  to  a  broad  range  of  ap¬ 
plication  domains,  have  a  much  lower  payoff  than  systems  that  are  narrowly  focused  on  one  or  two 
application  domains”  (Bigg87a).  The  functions  and  interfaces  of  the  domain  components  are  well 
documented  for  specific  applications,  making  it  easier  to  use  the  components  in  the  domain.  Do¬ 
main  specific  components  are  more  efficient  than  components  that  try  to  be  useful  to  many  do¬ 
mains. 

The  effort  involved  in  developing  a  specific  application  from  an  application  blueprint  is  much  less 
than  developing  the  system  from  scratch.  Since  the  framework  of  the  application  is  reused,  there 
is  a  minimal  design  effort  involved  in  tailoring  for  the  specific  application.  Coding  and  testing  ef¬ 
forts  are  reduced  because  large  components  of  the  system  have  already  been  developed  and  tested. 
Testing  efforts  can  also  be  reduced  by.  developing  a  generic  test  harness  for  applications  in  the  do¬ 
main. 

The  application  blueprint  promotes  greater  reusability  within  domains  by  providing  a  standard 
software  interface  to  the  functions  of  applications  in  the  domain.  If  this  standardization  can  be 
formalized  by  the  industry,  the  amount  of  reusable  analysis,  design,  and  code  will  be  greatly  in¬ 
creased  and  there  will  be  a  greater  potential  for  finding  acceptable  parts  for  the  applications.  This 
will  bring  software  reuse  closer  to  the  reusability  that  is  achieved  with  hardware  components. 

There  is  a  higher  degree  of  quality  in  the  specific  applications  developed  from  application  blue¬ 
prints.  The  design  of  the  specific  application  is  derived  from  the  generic  architecture  of  the  appli¬ 
cation  blueprint,  which  was  created  by  experienced  designers  in  the  domain.  This  design  has  to  take 
into  account  all  of  the  lessons  learned  of  the  experienced  design  team  to  produce  a  design  of  higher 
quality.  The  components  in  the  application  blueprint  have  been  coded  for  reuse  and  should  have 
few  defects.  As  the  components  are  used  in  specific  applications,  the  defects  in  the  components  are 
reduced. 

The  application  blueprint  provides  a  “consistency  in  the  implementation  and  behavior  of  the  ap¬ 
plications  that  share  the  architecture."  (Quan88)  Developers  working  in  the  same  domain  can  rap¬ 
idly  understand  the  complete  design  of  specific  applications.  The  blueprint  encourages  use  of  a 
common  terminology  throughout  the  domain.  Maintenance  activities  are  easier  because  main- 
tainers  familiar  with  the  application  blueprint  can  easily  maintain  the  specific  applications  in  the 
domain. 

The  application  blueprint  provides  good  support  for  early  prototyping  activities.  A  working  generic 
application  that  implements  the  major  components  of  the  system  can  be  used  as  an  early  prototype 
for  the  specific  applications.  Specific  application  developers  can  add,  delete,  and  modify  functions 
of  the  generic  prototype  to  develop  the  specific  application  prototypes. 
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Drawbacks 


The  major  drawback  of  the  application  blueprint  is  the  cost  of  developing  the  generic  system.  The 
entire  domain  must  be  understood  so  that  common  functions  can  be  determined  and  future  changes 
anticipated.  The  lifespan  and  the  potential  uses  of  the  application  blueprint  must  be  studied  to 
justify  the  cost  of  developing  an  application  blueprint.  Development  of  a  generic  architecture  is 
considerably  more  expensive  than  developing  a  specific  application  because  of  the  additional  anal¬ 
ysis  required  to  represent  the  requirements  of  many  applications  and  the  increased  effort  to  develop 
a  flexible  design  that  can  be  adapted  for  specific  applications  and  future  requirements. 

Using  an  application  blueprint  can  make  it  harder  to  adapt  to  changes  in  technology  because  each 
change  affects  many  specific  applications.  Technology  changes  need  to  be  planned  for  early  in  the 
development  of  the  application  blueprint. 

The  domain-specific  components  of  the  application  blueprint  are  less  reusable  outside  of  the  do¬ 
main.  Since  the  domain-specific  components  perform  domain  functions  and  are  highly  integrated 
within  the  generic  architecture,  they  are  harder  and  less  cost  effective  to  use  outside  of  the  domain. 
“Modules  become  less  and  less  reusable  the  more  specific  they  become,  because  it  becomes  more 
and  more  difficult  to  find  an  exact  (dr  even  close)  match  of  detailed  specifics”  (Bigg87a). 
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Organization  of  Software  Development  Groups 

Current  software  development  roles  need  to  be  altered  to  support  the  development  and  use  of  an 
application  blueprint.  Tnere  should  be  two  main  development  roles  within  a  software  organization, 
the  domain  engineers  and  the  application  engineers. 

The  domain  engineers  are  experienced  in  the  domain  analysis  process  and  are  considered  experts  in 
the  domain.  They  are  skilled  in  the  teclmiques  of  abstraction  and  domain  analysis.  Domain  engi¬ 
neer  responsibilities  include  identifying  the  domain,  performing  the  domain  Analysis,  and  creating 
the  application  blueprint. 

The  application  engineers  are  responsible  for  developing  an  application  in  the  domain.  They  use 
the  software  assets  developed  by  the  domain  engineers  and  obtain  domain  knowledge  from  the 
domain  engineers.  The  application  engineers  need  to  be  skilled  in  prototyping  techniques.  The 
application  engineers  provide  feedback  to  the  dom.'iin  engineers  to  improve  the  application  blue¬ 
print  for  use.by  future  domain  applications. 


|  DOMAIN  | 
I  INFO  I 


V  |  APPLICATION  | 

DOMAIN  . >|  BLUEPRINT  i 

ENGINEERS  |  j 

/\  . 

I 


feedback  of:  blueprint  change  requests, 
new  domain  knowledge, 
new  domain  components 


- >  SPECIFIC 

I  APPLICATION 


>  APPLICATION  . 

ENGINEERS  | 


SPECIFIC 

APPLICATION 

Y 


Figure  4.  Participants  in  Software  Development  Efforts 

Two  distinct  life-cycle  processes  are  required  to  support  the  development  of  application  blueprints 
and  their  use  in  developing  specific  application.  Application  development  efforts  typically  do  not 
have  enough  time,  money,  or  resources  to  develop  reuse  assets  for  payoff  in  later  application  de¬ 
velopment  efforts.  Development  of  an  application  blueprint  is  a  complex  and  costly  effort  requiring 
additional  investment.  Companies  need  to  realize  that  the  investments  in  application  blueprint  ef¬ 
forts  will  payoff  many  times  in  future  elicits  (Drak90). 
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Creating  an  Application  Blueprint 

It  is  recommended  that  domain  engineers  utilize  a  multi-disciplinary  team  to  create  the  application 
blueprint  so  that  multiple  views  are  represented  in  the  work  product.  Because  the  blueprint  will 
be  the  foundation  of  the  specific  applications  in  the  domain,  the  team  should  be  highly  experienced 
in  both  software  development  and  the  domain,  so  that  their  expertise  can  be  captured  for  use  in  the 
specific  applications  of  the  domain. 

The  process  for  creating  an  application  blueprint  is  shown  in  Figure  5  on  page  1 1. 


|  Identify  the  Domain  | 


PHASE  I  -  | 

DOMAIN  V 

MODELLING  . 

I  i 
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V 
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Figure  5.  Generating  an  Application  Blueprint:  Note  that  feedback  loops  are  not  shown  on  the  dia¬ 
gram,  but  occur  between  each  of  the  steps. 

There  are  three  phases  to  developing  an  application  blueprint: 

•  Domain  Modelling,  where  the  domain  is  identified  and  the  domain  analysis  is  performed 

•  Domain  Architecture,  where  the  generic  specification  and  design  is  produced 

•  Software  Asset  Development,  where  the  prototype  generic  system  and  domain  specific  com¬ 
ponents  are  developed 

The  steps  required  for  completing  each’  phase  of  the  application  blueprint  are  described  below. 

•  PHASE  I:  Domain  Modelling 

1.  Identify  the  domain 

The  domain  should  be  relatively  stable  and  contain  a  large  number  of  applications.  The 
boundaries  of  the  domain  need  to  be  identified  and  interfaces  to  the  external  entities  de¬ 
fined.  In  addition  to  defining  and  scoping  the  domain,  an  approach  to  the  domain  anal¬ 
ysis  and  the  sources  of  knowledge  and  information  about  the  domain  are  identified.  This 
step  also  includes  performing  a  cost  justification  for  developing  the  application  blueprint. 
There  should  be  enough  applications  in  the  domain  to  justify  the  upfront  cost  of  devel¬ 
oping  the  blueprint.  But,  it  may  be  beneficial  to  create  an  application  blueprint  for  a  small 
domain,  even  a  domain  with  a  single  application,  in  anticipation  of  future  needs  for  a  ge¬ 
neric  architecture. 

Several  guidelines  should  be  used  when  defining  the  domain  for  an  application  blueprint: 

■  The  applications  in  the  domain  should  perform  common  functions  so  that  they  can 
share  a  common  architecture. 

■  The  domain  should  be  defined  so  that  there  are  sufficient  applications  within  the 
domain  that  share  common  functions  to  justify  the  development  cost  of  a  generic 
architecture.  (Quan88) 

■  The  domain  should  be  sufficiently  large  and  stable.  “A  large  static  domain  means 
that  the  components  will  be  useful  for  longer  periods  of  time,  justifying  the  cost  of 
creating  the  components.  The  worst  kind  of  domain  for  reusability  is  one  where  the 
underlying  technology  is  rapidly  changing”.  (Bigg87a)  A  rapidly  changing  domain 
should  not  be  eliminated  until  it  is  determined  whether  the  high  level  generic  archi¬ 
tecture  for  the  domain  would  remain  stable,  even  though  the  lower  level  components 
change  over  time. 

■  The  hardware  and  software  environments  for  the  domain  applications  should  be 
similar  to  increase  the  chances  for  reusability  between  domain  applications. 

2.  Perform  Domain  Analysis 

In  the  domain  analysis  stage,  the  common  characteristics  of  the  application  in  the  domain 
are  identified  through  consultation  with  experts  in  the  domain  and  examination  of  existing 
applications  in  the  domain.  (Prie87)  This  is  the  most  critical  part  of  the  application 
blueprint  development. 

It  is  important  that  enough  effort  be  used  for  the  domain  analysis  since  it  is  the  foundation 
upon  which  the  application  blueprint  is  built  -  the  identification  of  common  requirements 
for  applications  in  the  domain.  From  experiences  in  performing  ten  domain  analyses, 
Neighbors  has  stated  that  it  typically  "takes  an  expert  in  a  particular  problem  area  four 
months  to  complete  a  first  attempt  at  the  domain.”  (Neig84)  "Careful  consideration  over 
a  long  period  of  time  is  required  to  produce  a  model  of  objects  and  operations  in  a 
problem  area  which  is  flexible  enough  to  last  through  the  ten  to  fifteen  year  lifespan  of  a 
large  system.”  (Neig84)  The  lifespan  of  defense  projects  is  typically  longer  than  this, 
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twenty  to  thirty  years.  The  objects  and  operations  of  the  domain  analysis  must  be  selected 
so  that  they  are  flexible  enough  to  last  the  lifespan  of  the  system. 

Two  types  of  domain  analysis  should  be  performed  during  the  domain  analysis  stage: 
horizontal  domain  analysis  and  vertical  domain  analysis.  “Horizontal  domain  analysis 
identifies  components  that  can  be  reused  across  a  broad  range  of  application  areas,  such 
as  data  structures  and  user  interface  mechanisms.  Vertical  domain  analysis  focuses  on 
isolating  portions  of  a  particular  application  that  can  be  reused  in  different  versions  of 
similar  applications  within  the  scope  of  the  same  problem  domain.”  (Trac87a) 

•  PHASE  II:  Domain  Architecture 

1.  Produce  the  Generic  Specification 

Use  the  information  collected  in  the  domain  analysis  to  produce  the  generic  specification. 
The  specification  describes  the  objects  and  operations  common  to  applications  in  the 
domain.  The  specification  must  be  written  in  the  language  of  the  domain  (i.e.  domain 
terminology)  so  that  it  can  be  reviewed  and  understood  by  the  experts  in  the  domain. 

2.  Build  the  Generic  High-Level  Design 

The  generic  high-level  design  is  the  framework  for  designing  specific  applications.  It  pro¬ 
vides  a  standard  set  of  interfaces  that  can  be  easily  adapted  to  support  the  requirements 
of  the  specific  applications  in  the  domain. 

Object  oriented  design  techniques  seem  to  be  the  best  way  to  enforce  this  mapping  be¬ 
tween  the  parts  of  the  application  blueprint.  The  domain  analysis  would  identify  objects 
and  classes  of  objects,  as  well  as  operations  on  the  objects.  By  using  object  oriented 
techniques,  the  generic  architecture  for  the  domain  will  be  more  likely  to  remain  stable 
as  the  system  changes.  The  scope  of  the  changes  can  be  isolated  to  individual  objects  of 
the  domain  that  are  loosely  coupled  to  the  other  objects  in  the  system.  Because  of  the 
loose  coupling  of  objects,  it  is  likely  that  the  effect  of  generic  architecture  changes,  for 
example,  adding  a  new  requirement  to  the  genenc  system  or  adapting  the  generic  archi¬ 
tecture  to  the  specific  application,  would  only  affect  a  small,  known  portion  of  the  existing 
system. 

•  PHASE  III:  Software  Asset  Development 

1.  Prototype  the  Generic  System  and  Develop  the  Set  of  Reusable  Components 

The  implementation  of  the  generic  system  consists  of  a  top  level  structure  for  the  domain 
and  a  set  of  reusable  components  specific  to  the  domain.  Because  these  components  are 
domain  specific,  they  should  be  relatively  large.  The  domain  components  must  be  thor¬ 
oughly  documented  to  describe  the  usage  of  the  components  within  the  applications.  The 
implementation  of  the  generic  framework  is  the  initial  prototype  of  the  specific  application 
development. 

Note  that  it  is  not  necessary  to  complete  each  step  of  the  process  before  proceeding  to  the  next  step 
or  next  phase  of  the  process.  A  better  method  would  be  to  go  through  the  steps  several  times,  using 
rapid  prototyping.  This  gives  the  domain  experts  early  results  for  review. 

Also  note  that  sometimes  it  will  be  necessary  to  repeat  previous  steps  to  account  for  new  knowledge 
about  the  domain.  For  example,  when  performing  the  domain  analysis,  the  identification  of  the 
domain  will  need  to  be  reconsidered  because  domain  boundaries  could  change  as  more  is  learned 
about  the  domain.  As  the  generic  specification  is  produced,  more  domain  information  may  need 
to  be  collected  through  domain  analysis. 

Development  of  a  generic  application  blueprint  is  an  ongoing  process.  As  applications  are  gener¬ 
ated  from  the  application  blueprint,  the  application  blueprint  should  be  updated  to  incorporate  the 
new  domain  knowledge.  In  particular,  the  collection  of  domain  specific  reusable  components  needs 
to  be  updated  to  include  the  newly  developed  components  and  increase  the  library  of  options  for 
future  applications. 


Creating  an  Application  Blueprint 


12 


Using  an  Application  Blueprint 

Figure  6  on  page  14  shows  how  an  application  blueprint  would  be  used  by  application  engineers 
to  develop  a  specific  application  in  the  domain. 

Given  that  a  generic  architecture  and  a  set  of  domain  specific  components  exist  for  the  domain,  a 
developer  of  a  specific  application  in  the  domain  would  use  the  i  ;plementation  of  the  generic  ar¬ 
chitecture  as  the  initial  prototype  of  the  system.  Customer  feedback  would  be  obtained  and  the 
prototype  would  be  modified  to  include  the  application  specific  requirements.  Specific  application 
changes  could  be  newly  coded  or  obtained  from  the  set  of  domain  specific  and  general  components 
in  the  repository.  Any  newly  developed  code  with  a  potential  for  reuse  should  be  submitted  to  the 
repository.  Also,  any  new  domain  knowledge  should  be  shared  with  the  developers  of  the  appli¬ 
cation  blueprint  for  incoiporation  into  the  blueprint.  When  the  customer  has  accepted  the  proto¬ 
type,  the  prototyping  phase  of  development  will  be  completed  and  the  developers  will  productize 
the  system. 
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Figure  6.  Using  an  Application  Blueprint 
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Use  of  the  IOM  Methodology  for  Domain  Analysis 

Many  methodologies  can  be  used  to  perform  the  domain  analysis.  We  developed  the  Air  Traffic 
Control  Application  Blueprint  using  the  Foxboro  Information  Object  Model  Methodology  for  the 
domain  analysis  to  evaluate  its  usage  in  the  development  of  the  application  blueprint. 

Note:  The  Overview  of  the  Information  Object  Model  was  based  on  talks  given  by  Dr.  Gerald 
White  of  Foxboro  Corporation. 


Overview  of  Information  Object  Model  Methodology 

The  Information  Object  Model  (IOM)  Methodology  was  developed  to  solve  the  problems  with 
using  traditional  structured  analysis.  It  is  modeled  after  the  Ward/Mellor  structured  analysis  tech¬ 
niques.  The  major  features  of  the  IOM  methodology  are  the  interview  techniques  used  to  perform 
the  domain  analysis  and  the  layered  presentation  of  information.  The  layering  of  information  forces 
the  analyst  to  push  the  details  of  the  system  to  lower  levels,  concentrating  on  the  specifications  of 
the  system  without  implementation  concerns;  the  “whats”  of  the  system  are  considered  before  the 
“hows”.  Functional  deliverables  are  a  requirement  of  the  methodology.  Graphical  techniques  and 
the  use  of  multiple  views  of  information  are  important  tools  for  recording  and  presenting  the  anal¬ 
ysis  information.  Expert  system  knowledge  acquisition  techniques  are  used  to  understand  the 
functions  in  the  domain. 

The  initial  work  products  of  the  Information  Object  Model  Methodology  are: 

•  Mission  Statement 

The  Mission  Statement  is  a  clear  concise  (one  page)  statement  of  what  the  system  does  and 
performance  requirements.  It  is  used  to  focus  the  team  on  the  task  and  define  the  boundaries 
of  the  task.  Customers  can  also  use  it  to  reach  agreement  on  the  task  definition. 

•  Overview 

The  Overview  is  a  ten  page  document  that  presents  an  overview  of  the  system  in  domain  ter¬ 
minology.  It  is  used  to  establish  the  system  boundaries  and  constraints  on  the  model.  It  also 
describes  the  major  functions  of  the  system. 

•  Information  Object  Model 

The  Information  Object  Model  is  a  layered  structured  analysis  of  the  system.  It  presents 
multiple  views  of  the  information,  combining  graphics,  a  data  dictionary,  and  user  generated 
text  to  functionally  describe  the  requirements  of  the  system.  It  is  the  functional  specification 
of  the  system.  The  Excelerator  tool  was  used  to  record  the  IOM  information. 

The  domain  information  for  the  IOM  is  obtained  through  interviews  of  domain  experts.  A  devel¬ 
opment  team  with  no  previous  experience  in  the  domain  should  be  used  to  reduce  implementation 
biases  in  the  early  phases  of  the  IOM.  Through  multiple  interviews  of  the  domain  experts  and 
presentations  of  multiple  views  of  the  acquired  domain  information  to  the  domain  experts  for  re¬ 
view,  the  developers  quickly  become,  knowledgeable  in  the  domain. 
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Applicability  of  IOM  Methodology  to  Application  Blueprints 

One  of  the  benefits  of  the  methodology  is  that  the  blueprint  developer  who  is  new  to  the  domain 
can  quickly  “come  up  to  speed”  on  the  domain  using  the  IOM  Methodology.  Interviewing  experts 
instead  of  reading  volumes  of  information  are  important  features  of  the  methodology.  The  know¬ 
ledge  of  the  experts  can  be  used  to  navigate  the  developer  quickly  through  the  domain  documen¬ 
tation. 

A  second  benefit  of  the  methodology  is  its  use  of  data  flow  diagrams  to  provide  a  layered  presen¬ 
tation  of  the  domain  information  in  the  terminology  of  the  domain.  These  diagrams  and  accom¬ 
panying  documentation  can  by  easily  understood  by  the  experts  of  the  domain  so  that  the  developer 
can  get  validity  checks  from  the  experts. 

The  initial  three  IOM  Methodology  work  products  correspond  to  the  first  steps  involved  in  creating 
an  application  blueprint.  The  Mission  Statement  for  a  generic  system  defines  the  domain  and 
identify  the  domain  boundaries.  This  is  one  part  of  the  domain  identification  step,  the  other  part 
being  the  cost  justification  for  the  development  of  the  application  blueprint  for  the  domain. 

The  Overview  would  be  a  work  product  of  the  early  stages  of  the  domain  analysis  task.  It  further 
defines  the  domain  and  identifies  the  major  functions  of  the  domain.  The  Generic  Specification 
step  is  represented  in  the  IOM  Methodology  as  the  Information  Object  Model.  It  is  the  functional 
specification  for  the  generic  system.  All  of  the  common  functions  of  the  domain  are  represented 
in  the  IOM. 

For  a  complete  discussion  of  the  IOM  Methodology  see  IBM  CDRL  1200A,  Information  Object 
Modeling  Methodology. 
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Lessons  Learned 


The  generic  application  blueprint  should  never  be  considered  completed.  As  specific  applications 
are  created  from  the  application  blueprint,  the  generic  model  should  be  revisited  to  add  new  in¬ 
sights.  Also,  as  new  components  are  developed  for  specific  applications,  the  components  should 
be  added  to  the  application  blueprint's  collection  of  domain-specific  components. 

Many  methodologies  could  be  used  to  develop  the  blueprint.  For  the  example  Air  Traffic  Control 
application  blueprint,  we  tried  the  IOM  Methodology  to  perform  the  domain  analysis  and  create 
a  generic  specification.  It  promotes  reusability  and  gives  a  clear,  layered  approach  to  the  domain 
analysis  and  systems  development.  It  would  be  beneficial  to  experiment  with  other  methodologies. 

A  highly  experienced  team  needs  to  develop  the  application  blueprint.  The  design  and  domain 
expertise  of  the  blueprint  developers  is  critical  to  the  quality  of  the  application  blueprint.  The  de¬ 
velopers  need  to  have  enough  experience  in  the  domain  to  anticipate  technology  changes,  so  the 
application  blueprint  can  be  useful  for  long  periods  of  time. 

Many  domains  contain  smaller,  more  reusable  domains.  Domains  that  appear  within  many  more 
specific  domains  need  to  be  identified.  These  domains  can  be  considered  subsystems  within  the 
specific  application.  Application  blueprints  for  these  domains  would  provide  a  standard  interface 
to  the  subsystems  and  maximize  reuse.  For  example,  the  Air  Traffic  Control  System  needs  to 
maintain  many  databases.  If  a  database  application  blueprint  existed  with  a  clearly  defined  standard 
interfaces,  then  it  could  be  tailored  to  the  ATC  needs  and  the  Air  Traffic  Control  System  applica¬ 
tion  blueprint  could  interface  to  the  subsystem. 

The  development  of  an  application  blueprint  can  easily  be  tied  to  the  Software-First  Life  Cycle 
(SFLC)  (IBM  1240)  phases  of  development.  The  domain  analysis,  generic  specification,  and  high 
level  generic  architecture  development  are  performed  during  the  Preliminary  System  Analysis  phase 
of  the  SFLC.  The  prototypes  for  the  generic  architecture  would  be  developed  during  the  System 
Architecture  phase  of  the  fife  cycle.  For  a  further  discussion  of  the  application  blueprint  in  the 
SFLC  see  Software-First  Life  Cycle  Final  Definition  (IBM  1240). 
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Recommendations  for  Future  Application  Blueprint 
Work 

The  following  is  a  list  of  recommended  areas  for  further  research  of  the  application  blueprint  con¬ 
cept. 

•  A  machine  processable  representation  for  the  blueprint  design  information  needs  to  be  devel¬ 
oped. 

A  major  hindrance  to  the  reuse  of  design  information  is  the  lack  of  a  machine  processable 
representation  of  the  design  information.  One  of  the  desired  features  of  a  design  representation 
is  that  it  have  “the  ability  to  create  partial  specifications  of  design  information,  specifications 
which  can  be  incrementally  extended"  (Bigg87a).  Existing  specification  languages  require  that 
all  details  of  the  system  be  specified.  The  idea  of  a  partial  specification  is  particularly  important 
to  the  application  blueprint  because  the  generic  architecture  provides  the  overall  framework 
of  the  system  which  is  refined  as  specific  application  requirements  are  added  to  the  design. 
The  representation  must  allow  for  partial  specification  of  the  details  of  the  system  so  that  the 
design  will  be  generic  and  reusable.  “If  we  insist  on  specifying  the  details  too  precisely,  we  over 
commit  to  the  details  of  the  resulting  component,  thereby  reducing  its  reuse  potential.  If  we 
leave  too  many  of  the  details  completely  unconstrained,  we  have  significantly  fewer  hooks  for 
automation  and  we  reduce  the  payoff  of  reusing  the  component  because  so  much  manual  labor 
is  involved.  Without  a  representation  that  allows  a  mixture  of  precision  and  fuzziness,  we  lose 
much  of  the  advantage  of  reuse”  (Bigg87a). 

The  design  representation  language  must  also  have  "the  ability  to  allow  flexible  couplings  be¬ 
tween  instances  of  designs  and  the  various  interpretations  those  instances  can  have”  (Bigg87a). 
"We  want  to  represent  the  essence  of  a  design  component  (factor)  rather  than  its  details,  per¬ 
mitting  us  to  apply  concepts  taken  from  one  domain  to  structures  within  an  entirely  different 
context."  (Bigg87a)  The  domain  language  must  have  referential  flexibility,  with  domain  terms 
referred  to  by  semantic  terms  rather  than  syntactic  names,  so  that  the  design  can  be  easily  used 
within  multiple  domains. 

Some  research  is  being  performed  by  Dr.  Mary  Shaw  (SEI,  Pittsburgh, PA)  to  investigate  ways 
to  describe  and  specify  architectures. 

•  The  retrieval  of  domain  specific  reusable  components  from  the  repository  should  be  studied. 

Users  of  a  parts  repository  typically  search  the  repository  to  retrieve  a  single  part  that  meets 
their  needs.  In  contrast,  application  blueprint  users  will  search  the  repository  and  retrieve  the 
collection  of  domain  specific  components.  A  single  retrieval  request  should  be  used  to  retrieve 
whole  subsystems  of  the  domain.  Domain  specific  retrieval  mechanisms  should  guide  the  ap¬ 
plication  developer  through  the  development  process.  The  majority  of  the  components  in  the 
domain  collection  will  be  reused  in  the  specific  application.  Organization  of  the  repository  by 
domain  should  also  be  studied, 

•  As  the  implementation  model  and  the  project  phase  of  the  Foxboro  IOM  methodology  is  de¬ 
fined,  it  needs  to  be  examined  for  its  applicability  toward  the  creation  of  application  blueprints. 

•  The  reuse  of  application  blueprints  within  more  specific  application  blueprints  needs  to  be  in¬ 
vestigated. 


Recommendations  for  Future  Application  Blueprint  Work 
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For  example,  the  reuse  of  a  database  application  blueprint  within  the  Air  Traffic  Control  ap¬ 
plication  blueprint. 

•  After  completion  of  an  application  blueprint  for  a  domain,  an  experiment  should  be  conducted 
to  develop  specific  applications  in  the  domain  to  test  the  concept  and  study  the  amount  of 
reuse  that  is  achieved  from  use  of  the  application  blueprint  and  the  gains  in  productivity. 

Further  work  is  needed  to  complete  the  Air  Traffic  Control  IOM  so  that  the  high  level  architecture 
can  be  developed  and  the  application  blueprint  completed.  This  includes  the  further  decomposition 
of  the  generic  functions  to  the  primitive  level. 


Recommendations  for  Future  Application  Blueprint  Work 
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Glossary 

adaptive  reuse:  A  form  of  reuse  where  higher  level  structures  with  clearly  defined  interfaces  are 
obtained  from  a  reuse  library.  New  code  is  written  for  the  lower  level  functions. 


application  blueprint:  A  means  of  capturing  analysis,  design,  and  implementation  information  for 
a  specific  domain  in  a  form  which  facilitates  reuse  in  that  domain.  The  blueprint  includes  a  generic 
functional  specification,  a  generic  high  level  design,  and  a  set  of  domain  specific  reusable  compo¬ 
nents. 


architectural  domain:  A  classification  for  a  domain  that  contains  a  set  of  applicaitons  that  share 
common  functions  and  can  use  a  common  architecture. 


compositional  reuse:  A  form  of  reuse  where  individual  components  are  used  from  a  library  of 
components.  New  code  is  written  to  “glue”  the  components  together. 


domain:  Encapsulation  of  a  problem  area. 


domain  analysis:  Common  characteristics  from  similar  systems  are  generalized,  objects  and  oper¬ 
ations  common  to  all  systems  within  the  same  domain  are  identified,  and  a  model  is  defined  to 
describe  their  relationships.  (PRIE87) 


generic  architecture:  A  high-level  design  that  define  standard  interfaces  for  applications  within  a 
domain. 


horizontal  domain  analysis:  “Identifies  components  that  can  be  reused  across  a  broad  range  of 
application  areas,  such  as  data  structures  and  user  interface  mechanisms."  (Trac87a) 

Information  Object  Model  (IOM)  Methodology:  A  methodology  based  on  Ward/Mcllor  structured 
analysis  techniques  that  promotes  knowledge  acquisition  techniques  and  a  layered  presentation  of 
information. 


problem  domain:  A  classification  for  a  domain  that  contains  a  set  of  applications  that  share  com¬ 
mon  functions. 


vertical  domain  analysis:  “Focuses  on  isolating  portions  of  a  particular  application  that  can  be 
reused  in  different  versions  of  similar  applications  within  the  scope  of  the  same  problem  domain.” 
(Trac87a) 


Glossary 
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Acronyms 


Acronym 

ATC 

CDRL 

IBM 

IOM 

SFLC 

SOW 

STARS 


Meaning 

Air  Traffic  Control 
Contract  Data  Requirements  List 
International  Business  Machines 
Information  Object  Model 
Software-First  Life  Cycle 
Statement  of  Work 

Software  Technology  for  Adaptable,  Reliable  Systems 


Acronyms 
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Appendix  A.  Application  Blueprint  for  Air  Traffic 
Control  Systems 

The  first  pass  of  the  generic  Air  Traffic  Control  (ATC)  Mission  Statement  and  Information  Object 
Model  is  included  in  this  appendix  as  the  generic  specification  of  the  application  blueprint  for  Air 
Traffic  Control  Systems.  It  was  the  result  of  the  Phase  2  work  of  the  STARS  IQM15  team  work. 
It  consists  of  Excelerator  graphs  and  reports. 

Domain  knowledge  was  obtained  through  numerous  ATC  documents  and  interviews  of  three  do¬ 
main  experts,  who  were  former  controllers.  One  of  the  experts  was  interviewed  at  the  beginning 
of  the  process  to  obtain  an  overview  of  the  ATC  systems.  This  information  helped  in  writing  the 
mission  statement  for  the  generic  ATC  systems.  The  second  expert  was  asked  to  review  the  mission 
statement  and  to  provide  information  about  the  major  functions  of  the  generic  ATC  system.  This 
information  was  used  to  prepare  the  Information  Object  Model.  The  third  expert  provided  addi¬ 
tional  information  about  the  domain  and  critiqued  the  first  pass  of  the  generic  ATC  Information 
Object  Model.  Since  the  IOM  development  team  had  little  ATC  domain  knowledge,  the  feedback 
from  the  domain  experts  was  important  to  ensure  the  validity  of  the  generic  ATC  IOM. 

To  complete  the  ATC  application  blueprint  the  generic  IOM  needs  to  be  completed.  Each  major 
function  of  the  IOM  needs  to  be  decomposed  to  the  primitive  level.  After  the  IOM  is  completed, 
the  generic  architecture  can  be  designed. 

For  further  information  about  the  IOM  task  and  the  generic  Air  Traffic  Control  System,  see 
STARS  IQM15  CDRL  1200,  STARS  Structured  Analysis  for  Selected  Application.  STARS 
IQM 15  CDRL  1200A,  Information  Object  Modeling  Methodology  discusses  the  IOM  methodology. 
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Mission  Statement:  Air  Traffic  Control 


The  proposed  mission  of  an  air  traffic  control  (ATC)  system  is  to  control  and  monitor  an  area  of 
defined  air  space  and  to  control  terminal  ground  operations.  This  system  provides  for  the  safe  and 
timely  departure  and  arrival  of  controlled  flights. 

An  ATC  system  will  provide  monitoring  of  aircraft  positions  in  relation  to  other  aircraft  traffic, 
terrain,  and  v/eather  conditions  within  a  defined  air  space.  An  ATC  system  will  provide  an  air  space 
situation  assessment  capability  to  identify  a  situation  for  the  control  function  to  manage. 

Control  for  an  ATC  system  will  provide: 

•  sequencing  and  separation  of  aircraft, 

•  navigation  instructions  to  avoid  identified  situations  (e.g.  conflict  alerts,  hazardous  weather, 
terrain  obstacles), 

•  for  the  tracking  of  controlled  aircraft  against  filed  flight  plans, 

•  navigation  instructions  to  aircraft  as  requested. 

Terminal  ground  operations  for  an  ATC  system  includes  control  of  ground  travel  and  issuance  of 
takeoff/landing  clearance. 

An  ATC  system  will  also: 

•  accept,  process,  allow  in-flight  modification  and  closeout  of  flight  plans, 

•  provide  communication  between  controller  and  aircraft, 

•  provide  weather  information  and  re-route  controlled  traffic  accordingly, 

•  provide  traffic  re-routing  due  to  exceptional  conditions  (e.g.  aircraft  emergency,  airport  closing, 
etc.). 

A  typical  scenario  for  operating  an  aircraft  under  the  guidance  of  an  ATC  system  includes  the  fol¬ 
lowing: 

•  Pre- Flight 

■  Flight  plan  entry 

•  Departure 

■  Push  back  clearance 

•  Taxi  clearance 

«  Take-off  clearance 

•  In-Flight 

■  Spacing,  monitoring,  and  tracking  of  aircraft 

•  Approach 

■  Sequencing  and  spacing  of  aircraft  to  determine  landing  order 


Mission  Statement:  Air  Traffic  Control 
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•  Landing 

■  Landing  clearance 

■  Taxi  clearance 

■  Docking  clearance 

•  Post-Flight 

■  Close-out  flight  plan 
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PASS  1 
EXCEL/RTS 


Alternate  Naie  Short  Descrip. 


Last  Modify  Date 


1.0  MONITORING  891024 

1.1  HEATHER  REPORTING  Perforis  the  gathering  of  surveillance  data  regarding  the  891027 

weather. 

1.1.1  SURVEILLANCE  DATA  FORMATTI  Perforis  gathering  and  formatting  of  surveillance  data  891027 

1.1.3  REPORT_FORMAT_AND_F!LTER  Gathers  weather  data  in  the  for#  of  weather  reports,  pilot  891027 

weather  reports  and  sury.  data  and  filters  it  for  CONTROL 

1.1.3  RESPONSE  TO  INQUIRY  Responds  to  pilots  request  for  weather  data  891027 

1.2  FLIGHT  MONITORING  Perforis  gathering  of  surveillance  data  of  aircraft  as  they  891027 

are  in-flight. 

1.2.1  FL:GHT_PLAN_PROCESSING  Accepts  flight  plans  and  revisions  and  sends  abbrev  flight  891027 

plans  to  CONTROL  and  active  flight  plan  info  to  TRACKING 

1.2.2  TRACKING  Tracks  targets  as  they  love  and  correlates  thei  to  flight  891027 

plans  if  available 

1.2.3  SURVEILLANCE  Perforis  gathering  of  flight  surveillance  data  for  TRACKING  891027 

and  CONTROL 

1.3  GROUND  MONITORING  Perforis  the  gathering  of  surveillance  data  at  the  891027 

airports.  Hatches  the  aircraft  on  the  ground. 

1.3.1  IDENTIFY_ACTiVE_AIRCRAFf  Identifies  active  (gate  to  runway)  aircraft  at  the  airport.  891027 

1.3.2  IDENTIFY JIQN-AIRCRAFT  Identifies  other  active  traffic,  besides  aircraft,  at  the  891027 

airport 

1.3.3  FORMAT  JiROUNDJURVEILLANCE  Coabines  the  airport  traffic  information  on  both  the  active  391027 

aircraft  and  the  active  non-aircraft  for  output  to  CONTROL 

2.0  CONTROL  CONTROL  receives  data  about  the  environment  r'roi  891027 

MONITORING,  and  performs  analysis  and  issues  control  inst. 

2.1  MANAGE  GROUND  TRAFFIC  Manages  ground  traffic  for  departures  and  arrivals.  891026 

DEPiRTURc  3RCUND  TRAFFIC  PROCESS  Manages  ground  traffic  for  departures.  Processes  TAXIING  891027 

requests  and  provides  ground  travel  plans. 

ARRIVAL  GROUND  TRAFFIC  PROCESSIN  Manages  ground  traffic  for  arrivals.  Processes  GROUND  391027 

CLEARANCE  request  end  provides  ground  travel  plans. 

2.2  MANAGE  FLIGHT  OPERATIONS  Manages  aircraft  ft  os  the  noient  the  aircraft  leaves  the  591026 

ground  until  it  once  again  reaches  the  ground. 

MANAGE JLJSHTjAKEDFF  Process  departures,  *'roi  the  tise  the  AIRCRAFT  reaches  the  S91027 

takeoff  runway.  Send;-  TAKEOFF  CLEARANCE  to  PILOT. 
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EXCEL/RTS 

Alternate  Naie 

Short  Descrip. 

Last  Modify  Date 

MANAGE.1N.FLIGHT 

Manages  AIRCRAFT  in  flight  (after  leaving  ground  up  to 

GROUND  CLEARANCE  request).  Provides  FLIGHT  CMOS  to  PILOT. 

891027 

2. 2. 2.1  INFLIGHT  REROUTING 

Rerouting  (ie.  changing  destination  or  way  points)  of  an 
aircraft.  Instructions  to  PILOT,  and  updated  flight  plan. 

891027 

2. 2. 2. 2  INFLIGHT  SESUENCING 

Sequences  (orders)  planes  for  arrival  or  through  points 
where  routes  »ay  intersect. 

891027 

2. 2. 2. 3  INFLIGHT  SPACING 

Spaces  aircraft  in  order  to  keep  the*  the  distance  apart  as 
indicated  in  the  RULES  AND  REGS. 

891027 

2. 2. 2. 4  WARNINGS  AND  ADVISORIES 

891024 

MANAGE_FLIGHT_ARRIVALS 

Manages  flight  arrivals.  Requests  GROUND  CLEARANCE  and 
provides  landing  instructions  to  PILOT  or  SIMULATION. 

891027 

FLISHT.NARNINGS.L.AOVISORIES 

Provides  WARNINGS  AND  ADVISORIES  to  PILOT.  Provided  info 
from  alerts  generated  in  2.3  SITUATION  ANALYSIS. 

891027 

2.3  FLIGHT  SITUATION  ANALYSIS 

Using  SURVEILLANCE  DATA  fro*  MONITORING,  calculates  re! 
pos.,  determines  alerts,  and  responds  to  pilot  inquiries. 

891026 

2.3.1  CALCULATE  RELATIVE  POSITIO  Calculates  the  distances  between  aircraft  and  other 

aircraft,  weather,  and  terrain  obstacles. 

391026 

2.3.2  EMERGENCY  PROCESSING 

Analysis  input,  checking  for  emergencies  caused  by  pilot/ 
aircraft  problems,  closed  airports/runways,  etc. 

891026 

2.3.3  HEATHER  AVOIDANCE 

Analyses  input,  checking  for  weather  hazords  and  produces 
alerts  based  on  the  weather  situation. 

991026 

2.3.4  HAZARD  DETECTION 

Analyses  input,  checking  for  hazards  such  as  conflict 
alerts  (2  aircraft  too  dose),  low  altitude  alerts,  etc. 

891026 

2.3.5  RESPOND  TO  INQUIRIES 

Receives  pilot  inquiries  about  the  weather/traffic/terrain 
and  responds. 

891026 

3.0  SIMULATION 

SIMULATION  provides  support  for  Controller  training  and  the 
testing  of  new  ATC  capabilities  before  field  installation. 

891027 

i.l  INITIALIZE  SIMULATION 

Uses  RECORDED  HISTORY  to  initialize  the 
environment  and  conditions  in  the  simulator. 

891027 

3.2  TRAFFIC  SIMULATOR 

Uses  controller  commands  and  INITIAL  SIMULATION 

SURVEILLANCE  RETURNS  to  calculate  new  traffic  positions. 

391027 

3.3  LGS  COMMANDS 

Logs  everything  that  needs  to  be  recorded  in  the  ATC  system 
log. 

891027 

J.O  LOGGING 

891024 
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4.1  DATA  TAGGER 

The  process  DATA  TASSER  identifies  the  type  of  log  data 
and  outputs  a  DATA  TYPE  tag  for  the  data. 

891027 

4.2  LOS  DECIDER 

The  process  which  based  on  the  LOGGING  DECISION  determines 
whether  log  data  of  an  identified  type  is  to  be  lagged. 

891027 

4.3  PROCESS  DATA 

PROCESS  DATA  filters  the  log  data  based  on  the  LOS  DECISION 
and  foraats  the  data,  and  writes  the  data  to  the  ATCJOB. 

891027 

5.0  TEST 

891024 

5.1  HEALTH  AND  HELLBEING  TEST 

Performs  general  health  tests  on  the  online  system. The  test 
type  and  frequency  are  based  on  the  ASSET  TEST  RBMTS. 

891027 

5.1.1  INITIATE  JEST 

Send  health  and  wellbeing  test  request  to  MONITORING  or 
CONTROL  and  inform  EVALUATE  TEST  RESULTS  of  test  request. 

891027 

5.1.2  EVALUATE  JEST.RES'JLT 

Evaluate  the  test  results  upon  test  compJetion,send  requests 
for  special  tests  to  SPECIAL  TEST  and  log  the  test  results. 

391027 

5.2  SPECIAL  TESTS 

This  process  perforas  online  special  tests  as  a  result  of  a 
log  data  anomaly  or  a  health  and  wellbeing  test  result. 

891027 

5.2.1  INITIATE  TEST 

Send  special  test  requests  to  MONITORING  or  CONTROL  and 
infora  EVALUATE  TEST  RESULTS  of  the  test  request. 

891027 

5.2.2  EVALUATE  TEST  RESULTS 

Evaluate  the  test  results  upon  test  completion  and  log  the 
test  results. 

391027 

5.3  EXAMINE  LOS  DATA 

This  process  exaaines  the  ATC  JOG  data  to  identify 
anomalies  that  require  further  testing  of  the  system. 

891027 

5.3.1  IDENTIFY  .ANOMALIES 

Examines  the  ATC  JOG  data  for  anomalies  using  the  ATC  TEST 
PARAMETERS  to  provide  equipment  and  operational  data. 

891027 

5.3.2  IDENTIFY  SPECIAL  TEST 

Based  on  the  input  ANOMALY  and  the  special  test 
requirements  in  ASSET  TEST  RBMNTS,  request  a  special  test. 

891027 

6.0  REFERENCE  UPDATE 

REFERENCE  UPDATE  provides  data  aanagement  services  for  all 
adaptation  data,  operational  procedures,  rules  L  regs,  etc. 

891027 

6.1  EDIT  REFERENCE  UPDATE  TRANS 

Data  for  updating  the  ATC  Reference  data  is  given  a 
validity  check  and  passed  to  the  update  procedure. 

891025 

6.2  UPDATE  REFERENCE  DATA 

The  validated  transactions  are  processed  and  the  REFERENCE 
DATA  data  stores  are  updated. 

891025 

AIC  Systea 
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H0025  ACTIVE_AIRCRAFT  Aircraft  which  are  active  in  ground  operations,  fro*  gate  391027 

to  runway. 

H0026  ACTIVE.NON-AIRCRAFT  Other  ground  traffic,  such  as  trucks,  which  aust  he  891027 

identified  and  avoided  during  aircraft  ground  travel 

K0049  ADVISORIES JIARNIHGS  Warnings  and  advisories  given  to  the  PILOT.  Generated  froa  391027 

the  ALERTS  passed  to  2.2.4  FLIGHT  WARNINGS  AND  ADVISORIES. 

£0003  AIRPORT.AND.ASSET.STATUS.DATA  Dynaaic  data  describing  the  airport  status  and  the  avail-  891025 

ability  or  non-availability  of  critical  airport  assets. 

K0046  ALERTS  Alerts  generated  by  FLIGHT  SITUATION  ANALYSIS,  consists  of  891027 

Eaergency,  Heather,  and  Hazard  alerts. 

J0019  ANOMALY  A  discrepancy  in  the  ATC.LOG  data.  891027 

K0031  ASSISNED_MOD_ARR_SRD_TRAVEL_PLAN  Travel  plan  given  to  the  PILOT  by  MANAGE  GROUND  TRAFFIC  for  891030 

arrivals. 

K0036  ASSIB»ED.H0D.DEP.6RD_TBAVEL.PUW  Travel  plan  given  to  the  PILOT  and  MANAGE  FLIGHT  OPERATIONS  391030 

by  MANAGE  GROUND  TRAFFIC  for  departures. 

E0001  ATC.FR3CEDURES  Operating  procedures  for  ATC  site  laintenance  ano  testing  891026 

of  site  assets. 

H0030  BEGIN/END.SIMULATIGN.REQUEST  Request  coning  in  fros  the  Air  traffic  adiinistration  to  •  891027 

have  the  ATC  systei  put  in  siaulation  sode. 

'<0038  CANCEL.CLEARANCE.REQUEST  Cancel  the  CLEARANCE  REQUEST  issued  for  flight  indicated  by  891030 

the  FLIGHT  PLAN  ID. 

<0041  CANCEL.GROUND.CLEARANCE  Cancels  GROUND  CLEARANCE  given  for  flight  identified  by  891030 

FLIGHT  PLAN  ID. 

30003  COMMUNICATIONS  Coanuni cat ions  that  go  fros  SIMULATION  to  CONTROL  and  back.  091027 

May  include  Pilot  requests. 

<0018  COMMUNICATIONS  Coiiunication  to/froa  the  PILOT.  Includes  requests  to  391027 

takeoff/land,  navigation  inst.,  inquiries,  warnings,  etc. 

<0009  CONTRQL.LOG.DATA  Data  generated  by  CONTROL  to  be  logged.  Includes  alerts  891030 

and  coiiunication  to  the  AIRCRAFT. 

H0015  CGRRELATED.FLIGHT.DATA  Surveillance  Data  and  Flight  Plans  that  have  been  satched.  391027 

Today  shows  which  flight  plan  goes  with  which  radar  blip. 

K0043  EMERGENCY.ALERT  Alerts  generated  by  2.3.2  EMERGENCY  PROCESSING,  because  of  891027 

PILOT  PROBLEMS  or  sone  change  in  AIRPORT  L  AP  ASSET  STATUS. 

KC012  EMERGENCY_CONTROL.LOG.DATA  Data  logged  by  2.3.2  EMERGENCY  PROCESSING.  Includes  ALERTS  891027 

generated  due  to  eiergencies  lie.  PILOT  PROBLEMS). 
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K0050 

F1LTERED.RESP0NSE 

Response  given  to  PILOT  fay  2.3.5,  RESPOND  TO  INQUIRIES. 

891030 

H0Q07 

FILTERED.HEATHER.REPQRTS 

Incoting  weather  data,  weather  reports  and  pilot  reports, 
that  has  been  filtered  for  use  by  the  CONTROL  function 

891027 

K0051 

FLIGHT.COMMANDS 

Navigation  instructions  frot  MANAGE  INFLIGHT  to  the  PILOT. 

891027 

K0003 

FLJGHTJNSTRUCTIGNS 

Flight  instructions  fro*  CONTROL  to  the  AIRCRAFT,  include 
navigation  inst.,  clearances,  ground  routes,  etc. 

891027 

H0023 

FLIGHT.INSTRUCT10NS 

Cotiands  fro*  CONTROL  telling  traffic  what  action  to 
perfor*. 

891027 

H0013 

FLI6HT.PLANS 

Itinery  of  a  particular  flight  which  is  entered  by  prior  to 
a  flight  co»*encing.  Also  includes  beacon  code,  etc. 

891122 

H002A 

FLIGHT.PLAN.DATA 

Flight  plan  data  that  is  required  by  TRACKING  to  perfor* 
correlation  between  flight  plans  and  identified  targets. 

891027 

K0033 

FLiGHT.PLAN.ID 

indicates  a  specific  flight  plan  land  therefore  a  specific 
AIRCRAFT)  within  the  syste*. 

891030 

H0023 

FORMATTED.SURVElLtHNCE.DATA 

Surveillance  weather  data  that  is  foraatted  for  use  by  the 
REPORT  FORMAT  AND  FILTER  function 

891027 

H0006 

FORMATTED .HEATHER.DATA 

Heather  surveillance  data  that  has  been  foraatted  for  use 
by  the  CONTROL  function 

891027 

£0002 

GAA.DATA 

Data  provided  by  the  <GENERIC>  Aviation  Agency  to  establish 
the  policy,  procedures  and  operating  parameters  for  ATC  ops. 

891026 

J0044 

GAA.REBUIRED.REPORTS 

General  Aviation  Agency  requested  reports  generated 
fro*  the  log  data. 

891027 

K0040 

GROUND.CLEARANCE 

Indicates  the  ground  is  clear  for  an  AIRCRAFT  to  land. 

Given  to  2.2.3  MANAGE  FLIGHT  ARRIVALS. 

891030 

K0057 

GROUND.COMNUN 1 CAT  ION 

CoMumcation  between  CONTROL  and  N0N.AIRCRAFT  GROUND 
TRAFFIC,  for  the  purpose  of  controlling  runway  traffic. 

891 106 

40022 

GROUND  JIONITGRINS.LQG.OATA 

Logged  data  fro*  the  GROUND  MONITORING  function. 

89102?' 

K0048 

5R0UND.T0.A1R.HAND0FF 

Indication  to  2.3  SITUATION  ANALYSIS  that  AIRCRAFT 
(indicated  in  rec.)  has  left  the  ground. 

891027 

H0021 

6RG0ND.TRAFFIC.SURVEIII.ANCE.DATA  Surveillance  data  about  ground  traffic  at  an  airport. 

891027 

K0032 

HAZARD.ALERT 

Using  SURVEILLANCE  DATA  and  REL  P0S,  deteraines  hazards 
such  as  CONFLICT  ALERT  and  L0H  ALTITUDE. 

391027 

K0027 

HA2ARD.CGNT0RL.L06.0ATA 

Log  data  generated  by  2. 3. A  HAZARD  DETECTION  includes 

891027 

hazard  alerts. 
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JOOIO 

HEALTH_AND_H£LLSEING_ACK 

Sent  by  MONITORING  and  CONTROL  indicating  that  the  Health 
and  being  test  was  perfoned.lt  includes  the  test  results. 

891027 

J0009 

HEALTH_AND_NELL8EINS_REf!UEST 

A  request  to  MONITORING  or  CONTROL  that  a  Health  and 
Heiibeing  test  be  perforied. 

891027 

J0014 

HEALTH, AND_NELL8E!N8_SPECIAL_T£S  HEALTH  AND  HELLBEING  request  for  a  special  test  resulting 

free  a  proble*  during  the  Health  and  Heiibeing  test. 

891027 

K0052 

INFLI6HT.HAND0FF 

Sent  fro*  2.3  SITUATION  ANALYSIS  to  2.2.2  MANAGE  IN-FLIGHT 
to  indicate  when  a  plane  is  not  the  respons.  of  FLGHT  ARRVLS 

891030 

H0027 

IHITIAL.SIHULATIOM.DATA 

891025 

K0028 

INBUIRY.RESPONSE.CONTROl  LOG.DAT  Data  logged  by  2.3,5  RESPOND  TO  INQUIRIES.  Includes  PILOT 

request,  and  the  response  to  the  request. 

891027 

E0007 

INVALID, ATC_TRANS 

ATC  Transactions  rejected  for  update  by  UPDATE  REFERENCE 

DATA 

891024 

E0004 

RIVAL I D_GAft_TRANSACT I DNS 

GAA  Transactions  not  accepted  for  update  by  UPDATE  REFERENCE 
DATA. 

391025 

J0008 

LOB81NB.DEC1S10N 

Infor*ation  fro*  the  AC_ANS_ENV,DATA  indicating  the  types 
of  log  data  to  be  saintained  in  the  ATC.LDG. 

891027 

J0004 

L0G_DATA 

The  processed  log  data  stored  in  the  ATC.LOG, 

891027 

J0007 

L06.DECIB10N 

A  decision  deterained  by  LOG  DECIDER  indicating  whether 
the  log  data  of  an  identified  type  should  be  logged. 

391027 

HOOOS 

MHIT0RIHB.lfl6.DAW 

Data  logged  by  the  MONITORING  function 

891027 

K0014 

NON.CLOSED.rLIGHT.PLAN.NESSABE 

Message  generated  to  the  external  Search  and  Rescue  entity 
when  a  plane  is  overdue  according  to  its  flight  plan. 

891027 

<0053 

PllOT.FROSLEM 

Proble*  reported  by  the  pilot,  such  as  aircraft 
e*ergencies,  etc. 

891030 

.<0054 

PILOT.REOUESTS 

Request  fro*  the  PILOT.  Includes  requests  such  as  request 
for  reroute,  or  infor*ation  about  weather,  traffic,  etc. 

891030 

<0030 

PILOT.REQUEST.FOR.REROUTE 

Sent  fro*  2.3.5  RESPOND  TO  INQUIRIES  to  2.2.2. 1  INFLIGHT 
REROUTING  when  the  PILOT  requests  a  reroute. 

891030 

H0002 

PILOT.HEATHER.REPORTS 

Any  weather  data  reported  by  pilots 

891027 

HOOli 

PREOICTED.FLIGHT.DATA 

Predictions  about  the  future  path  of  identified  aircraft 
while  in  flight.  Used  to  predict/prevent  collisions. 

891027 

J3004 

SEFERENCE.L03JATA 

391024 
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E0005 

REFERENCE.UPDATE.LOG.DATA 

Log  lessages  of  REFERENCE  UPDATE  tables  to  be  recorded  by 
LOGGING. 

891026 

K0047 

RELATIVE.POSITIONS 

Distance  (long,  lat,  and  altitude)  between  an  aircraft  and 
other  aircraft,  weather,  and  terrain  obstacles. 

891030 

K0039 

REQUEST.FOR.GROUND.CLEARANCE 

Request  for  GROUND  CLEARANCE  for  flight  indicated  by 

FLIGHT  PLAN  ID. 

891030 

K0042 

REQUEST.F0R.6R0UND_TRAVEL.INST 

Request  for  ground  travel  plan  on  arrivals. 

891027 

K0034 

RESUEST.FOR.PUSHOFF/TAXI 

Request  froi  the  PILOT  to  pushoff  froi  the  gate  and  taxi  to 
the  takeoff  runway. 

891027 

X0055 

RESUEST.LANDING.INSTRUCTIONS 

PILOT  request  to  2.2.3  MANAGE  FLIGHT  ARRIVALS  for  landing 
instructions,  including  which  runway. 

891030 

K0014 

REROUTING  CONTROL  LOG  DATA 

Data  generated  by  2.2.2. 1  INFLIGHT  REROUTING  to  be  logged. 
Includes  new  routes  and  updated  flight  plans. 

891027 

K0035 

RESPONSE.FGR.PUSHOFF/TAX I 

Response  froi  2.1.1  DEPARTURE  GROUND  TRAFFIC  PROCESSING  to 
the  PILOT  to  his  request  to  pushoff/taxi. 

391027 

K0013 

RULES.AND.REGS 

891025 

K0015 

SEQUENCING.  CONTROL.LOG.  DATA 

Data  generated  by  2.2.2.2  INFLIGHT  SEQUENCING  to  be  logged. 

891027 

H0012 

SIMULATION  SURVEILLANCE  RETURNS 

Siaulated  surv.  returns  (such  as  RADAR  and  weather)  used  by 
MONITORING  and  CONTROL, 

391027 

H0029 

SIMULAT10N.L0G.DATA 

Data  that  needs  to  be  written  to  the  hTC  systei  log. 

891027 

H0009 

SIHULATION.SIGNAL 

Boolean  signal  telling  CONTROL  and  MONITORING  the  the 
systei  is  in  siiulation  tode. 

891122 

H0001 

SITE.MEATHER_SURVE1LLANCE.DATA 

Heather  data  leasured  at  a  particular  site--  today  includes 
radar  data  and  specific  aeasureientsle.a.,  baroietnc  press) 

891027 

K0026 

SPACING.CONTROL.LOG.DATA 

Data  generated  by  2.2.2.3  INFLIGHT  SPACING  to  be  logged. 

891027 

H0032 

SPECIAL.! NTEREST.REPORTS 

Reports  provided  to  the  goverment  regarding  any  events 
of  special  interest  (e.g.,  presidential  entourage). 

391027 

H0031 

SPECIAL. INIEREST.REPORT.RESUEST 

Request  by  goverment  for  report  of  interest  to  goverment 

891027 

J0013 

SPECIAL.TEST.ACK 

An  acknowledgeient  froi  MONITORING  or  CONTROL  that  the 
special  test  was  perfoned.Test  results  are  included  in  ack. 

391027 

■30016  SPEC  1  flL_TEST_ INITIATED 


A  signal  to  EVALUATE  TEST  RESULTS  fro*  INITIATE  TEST  to 
indicate  that  a  test  request  was  issued. 


391027 
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J0017 

SPECIAL.TEST.REBUEST 

A  request  to  MONITORING  and  CONTROL  that  a  special  test 
be  perforaed. 

891027 

J0013 

SPECIAL_TEST_RESU£ST_FROM_LOBSIN  EXAMINE  L06  DATA  request  Tor  a  special  test  resulting  froi 

an  anoialy  detected  in  the  ATC  LOS  data. 

891027 

J0049 

STATUS.EVENT.REPORTS 

ATC  status  reports  generated  froi  the  log  data. 

891027 

H0018 

STRIPS. (PLANNED/NONPLANNED.FLTS)  Abbreviated  Plight  plan  data  for  use  by  the  CONTROL 

function  in  spacing  and  sequencing  functions. 

891027 

K0006 

SURVEILLANCE.DATA 

Data  passed  froi  MONITORING  to  CONTROL  which  contains 
information  about  the  environient  (weather  and  traffic). 

391027 

K0044 

TAKE0FF.CLEARANCE.RE8UEST 

Request  froa  the  PILOT  to  2.2.1  MANAGE  FLIGHT  TAKEOFF  to 
takeoff.  Plane  is  at  the  end  of  the  runway. 

891030 

K0045 

TAKEOFF.CLEARANCE.RESPONSE 

Response  to  TAKEOFF  CLEARANCE  REQUEST  froa  2.2.1  HANAEE 
FLIGHT  TAKEOFF  to  PILOT.  Allows  PILOT  to  takeoff. 

891030 

H0017 

TAR6ETJMA6ES 

Identified  aircraft  in  the  airspace  (e.g.  radar  blips) 

891027 

HOOI! 

TENTATIVE.FLIGHT.PLAN 

Data  about  a  flight  that  does  not  have  an  associated  flight 
plan. 

89102? 

H0020 

TERRAIN.SURVEILLANCE.DATA 

Raw  surveillance  data  about  the  terrain. 

891027 

H0034 

TEST.ACK 

Acknowledgement  back  to  the  TEST  function  at  the  completion 
of  the  requested  test. 

891106 

J0015 

TEST.IIIITIATED 

A  signal  to  EVALUATE  TEST  RESULTS  fro*  INITIATE  TEST  to 
indicate  that  a  te,.v  request  was  issued. 

991027 

H0033 

TEST.RE9UE5T 

Request  by  the  TEST  function  to  perfori  a  health/well  being 
or  special  test. 

891106 

J0005 

TEST.RESULTS 

Data  generated  by  TEST  to  be  logged.  It  includes  the 
results  fio*  the  Health  and  Wellbeing  and  Special  Tests. 

89 1027 

HOOl? 

TRAFFIC.31JRVEILLANCE.DATA 

Raw  surveillance  data  (e.g.,  radar)  on  aircraft. 

891027 

30035 

UPDATED.FL1GHT.PIAN  DATA 

Revised  flight  plan  data  for  a  particular  flight  which  was 
revised  automatically  by  the  TRACKING  function 

891106 

H0010 

UPDATED.FLISHT.PLANS 

■Updated  flight  plans  as  received  from  the  CONTROL  function, 
necessary  due  to  rerouting  and  pilot  requests. 

891027 

K0007 

UPDATED.FL1GHT.PLANS 

Updates  for  flight  plans  do  to  reroute.  Sent  froa  CONTROL 
to  MONITORING  and  FLIGHT  PLAN  ENTERER. 

S91030 

E0004 

VAL IDATED.SEF.UPD.TRANSACTIONS 

Validated  transactions,  to  be  processed  by  UPDATE  REFERENCE 
OATA  and  stored  in  the  appropriate  data  stores. 

891025 
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K0056  HEATHER.ALERT 

Using  SURVEILLANCE  DATA  and  REL  POS,  deteriines  weather 
hazards  such  as  strong  winds  or  thunderstoras. 

S91027 

K0016  HEATHER. ALERT.CONTROLJ.OS_ DATA 

Data  logged  by  2.3.3  HEATHER  AVOIDANCE.  Included  HEATHER 
ALERTS. 

891027 

H0003  HEATHER.REPORTS 

Heather  reports  provided  by  an  external  agency,  provides 
forecasted  weather  for  exaiple 

891027 

H0004  HEATHER J?EP0RT_RE8UESTS 

Request  by  a  pilot  for  weather  data. 

891027 

H0008  HEATHER.REPORT.RESPONSE 

Response  to  the  pilot  to  his  request  for  weather  data 

891027 

